Cream of the Crop 25/Cream of the Crop 25.iso/os2/faxd_07.zip/CHANGES.V07

Text File | 1997-04-02 | 7KB | 145 lines

CHANGES in V03

Besides cosmetic changes, v03 addresses the problem that some OS/2
sendmail commands require '-a' and some, '-af' in the command line.
A line is added to the faxd.cfg file.  The default is:  '-a'.  If you
need -af, then just add the 'f'.  No quotation marks needed.



CHANGES IN V04

I decided to use semaphores instead of data queues for event
triggering between and among threads.  This means that you will have
to install the REXXIPC.DLL (included in an internal ZIP file) in your
OS2/DLL directory.

I split the email thread off as a third working thread (in addition
to the main thread and the clock thread).  It will eventually handle
other notification chores -- involving error handling.

I added four displays to the main thread's window:  a clock tick
indicator and three "lights" for the three semaphores.  These
indicators are probably temporary -- so that I can watch what is
happening when I make changes.  They add overhead.

I began building some exception handling into the worker threads.
Missing file names or fax numbers ought to result in the skipping and
renaming of the file being worked on.  (The last letter is changed to
an underscore.)  Over time, as I identify things that stop a thread,
I will try to catch them before they happen.

I also built in a thread kill and restart facility for each of the
three worker threads.  At the designated intervals, the main thread
"posts" the worker thread's semaphore.  That triggers the worker
thread to do its job.  The worker thread also "resets" the semaphore.
If the main thread notices during subsequent cycles that the
semaphore has not been reset, it waits for a few cycles and then
kills the thread, renames the current file it was working on and
restarts it.  The number of cycles it waits is (rounded down to the
next whole number)

For thread 1:  20 divided by the number of ten second tics in a
cycle.

For thread 2:  10 divided by the number of ten second tics in a
cycle.

For thread 3:  Twice the number for thread 2.

The idea is to give a process time to complete before panic sets in.

The three semaphore lights keep track of the progress.  Yellow means
that the threads are in an unknown condition or in transition.  The
program starts in yellow.  Green means the thread is posting and
resetting normally.  The light comes on (lighter green) when the post
is sent by the main thread.  It goes off when the reset is sent
(there is a small built in delay).  If a reset is missed, it goes to
yellow and begins to keep count of the missed cycles.  Next it goes
to red.  It flashes on (lighter red) at the post events.  A big fax
and a short cycle can easily send the Sem1 light into the red.  But
there ought to be plenty of headroom.

I am not sure what error codes Sendmail returns.  If FAXD does not
get a '0' from Sendmail, it renames the email file.

The next version will probably increase the amount of exception
handling and include notification that a "job" has been rejected or
that it has caused thread death.  At the moment, it just leaves the
carcass of the offending job in the directory.

FXFTP.EXE has also been changed a bit.  I added a button to preview
the fax or file.  You have to add another line in the FXFTP.CFG file
with the command to launch the viewer app.  For example:
d:\faxworks\faxworks.exe.  the program issues this command followed
by the file name.  You can also use:  start d:\faxworks\faxworks.exe
to get rid of the command session.  Or you can use another program,
like SPView or Review.  If you edit the file in FaxWorksand resave
it, however, you will have toopen the new fax under the new number.

CHANGES IN V07

Lots of changes!

The Configuration file has changed.  The 6th and 7th lines now are in
SECONDS and refer to minimum and maximum interval for activity.

Only the Thread that checks for Envelope files is active on launch.
the other two are quiet -- reflected by Yellow lights on the control
panel.  They become active only while there is an active job.  This
cuts down on overhead.

The program starts by checking at intervals as set by the minimum
interval number in the config file -- line 6. Over two hours, it
increases this to the interval set by line 7. As soon as a job is
detected, however, it resets to the most frequent and starts the
process over.  I think of the longer setting as the interval I want
it to use in the background under normal circumstances.  The faster
pace is like one's heart speeding up when there is activity.

I have modified the thread restart feature.  It now counts up to a
number that is based on the interval being used and the number of
jobs the first thread was working on.  The busier the program, the
more time will elapse before it decides a thread has crashed.

The program now sends out email messages informing you that a file
has caused an error or has crashed a thread.

I changed the way Semaphores worked to allow multiple instances on
one machine.  Run each one is a separate directory!  With its own
config file.

FaxD tries to keep itself up and running by monitoring its threads
and restarting them if needed.  I intend this for long unattended
operation.  So I also wrote a small program to launch FaxD and
monitor its status.

FaxDGo is basically a loop.  It starts FaxD and waits for it to
close.  When FaxD closes, FaxDGo loops around and restarts it.  What
makes FaxDGo a bit different, is that it also starts a thread to
monitor FaxD.  It uses an interprocess queue -- with a name based on
its own PID -- to check on FaxD.  This takes place in the main thread
of FaxD in the off clock cycles -- the ones where no processing took
place.  It supplies FaxD with the Queue name at launch time.  If FaxD
sees the queue name, it checks the queue every ten seconds and, if
the queue is empty, it places its PID in it.  At the other end, the
monitor stores the PID and checks every minute by emptying the queue
and rechecks on the next cycle.  If the queue is empty, FaxDGo, after
a few 5 second rechecks, kills the FaxD PID and restarts FaxD.

There have been some last minute changes to FaxDGo to allow
running multiple instances, and the revisions have not been
tested.

Now, the problem is trying to get rid of FaxD.  It just will not go
away if started with FaxDGo.  So, I include a CMD file called
FaxDStop.CMD.  Until you run FaxDGo, this command file is not
functional.  Each time you run FaxDGo, it changes FaxDStop by
inserting its PID in the REXX file.  Don't rename it! Running
FaxDStop kills FaxDGo and FaxD.

Except for debugging and logging, this is as far as I want to go with
this project.  I am, however, rewriting the whole thing using Object
Rexx as my next project.